Days before the French president’s death, hours before the New Year, moments before a napkin was removed from his face, François Mitterrand ate two birds whole—bones, beaks, and all.
The practice has been outlawed since 1999; however, in the closing hours of 1995, Mitterrand ate the ortolans and promptly died eight days later.
Had he lived longer, Mitterrand would have struggled to justify his behavior. The cruelty of drowning birds would have been reason enough to back away from the table. Additionally, his socialist sensibilities must have been vexed by such a meal, featuring a dish so shameful that the napkin was said to hide the guilty from the eyes of God.2 Yet, Mitterrand ate it anyways. Twice!
Are human beings rational? If we were, then certainly we would not ride motorcycles, wear high-heeled shoes, pay more for brand-name products, flirt with bad boys and bad girls, prefer expensive over inexpensive wines, or eat endangered songbirds, among other things. Although we make some rational decisions, we make far more irrational ones.
We buy an expensive dress because “it is on sale.” We play a violent video game all day because we “need to relax.” We let children play tackle football, because “exercise is healthy.” We make irrational decisions then reframe them as rational. Psychologists call this behavior post-hoc rationalization.
Post-hoc rationalizations shape how we create products. We produce a successful or failed product then retroactively justify why it is so. Process methodologies result from post-hoc rationalizations. Agile. Scrum. Kanban. Lean. Google Design Sprints. DevOps. V-Model. Extreme Programming. Rapid Application Development. Capability Maturity Model Integration. Waterfall. Whatever. Methodologies have their merits, but they pale in comparison to reason. Rational decision-making can make nearly any project successful; a misapplied methodology can turn a golden goose into a vampire bat.
We can avoid post-hoc rationalization’s worst effects by recording our reasoning at the time we make a decision. We all rationalize; we need not compound it with forgetfulness. Documents need not be elaborate or exhaustive; a simple annotation will often suffice. As Parnas and Clements’ paper, “A Rational Design Process: How and Why to Fake It”,3 argues, the main benefit of documentation is retrospective: it allows future designers to understand not how decisions were made but why.
Post-Hoc Fallacy
Post-hoc fallacies may occur in marketing, economics, legal systems, and even the user experience of software. Software users frequently engage in post-hoc fallacies. They believe online forms submit faster when they repeatedly mash buttons. They believe comments are most easily read when written in ALL CAPS. They believe computers screens last longer when they use a screen saver. They believe free shipping is actually free.
Although post-hoc rationalizations and fallacies riddle user experience, we need not remedy every misconception. Some may even be beneficial. If we realized our lack of online privacy, we might stop communicating. If we recognized our lack of security, we might stop discovering. If we understood all the challenges of living and working in today’s digital world, we might stop advancing all together. A little bit of rationalization can be a good thing, allowing us to move forward and our ideas to take flight.
Key Takeaways
Post-hoc rationalizations retroactively justify outcomes.
Post-hoc fallacies are formed when we mistake correlation for causality.
Rationalization and fallacy can worsen or improve user experiences.
Questions to Ask Yourself
What post-hoc rationalizations do I and my team make?
How can I best document a key project decision?
What post-hoc rationalizations do my users make?
Does an experience account for users’ post-hoc fallacies, such as repeated form submissions?
How can I ethically leverage user rationalizations to lead users to better outcomes?